#46744 Prevent the default role from being set to a privileged role when user registration is open - #12977

Why Is there a static variable in use here? It feels unnecessary

Filtering the option on read rather than clamping it on write has three consequences downstream that I don't think are intended. I verified each against trunk:

1. The companion Site Health check can no longer fire. WP_Site_Health::get_test_insecure_registration() — added in 7.0.0 for this same ticket — does:

if ( $users_can_register && in_array( $default_role, array( 'editor', 'administrator' ), true ) ) {

It reads get_option( 'default_role' ), which is now filtered. Its critical branch requires users_can_register to be truthy, which is exactly the condition under which filter_default_role() has already rewritten the value to subscriber. So the branch becomes unreachable: the one screen that warned owners about this configuration reports "good" while the database still holds administrator.

2. An admin can no longer save a corrected value. update_option() at option.php:887 does $old_value = get_option( $option ); — the filtered value — and then returns early:

if ( $value === $old_value || maybe_serialize( $value ) === maybe_serialize( $old_value ) ) {
	return false;
}

With administrator stored and registration open, get_option() returns subscriber, so selecting "Subscriber" in Settings > General writes nothing. "Settings saved", database unchanged. The privileged value stays until someone turns registration off, at which point the clamp lifts and the site silently resumes creating administrators.

3. WP_Roles::remove_role() breaks on the same comparison — class-wp-roles.php:217 uses if ( get_option( 'default_role' ) === $role ) to reset the default when the role is removed, and that can no longer match the stored value.

All three go away if enforcement moves to write time. sanitize_option() already has a default_role case at formatting.php:5165 handling the missing-role fallback, which looks like the natural home; pre_update_option_default_role would also work. Stored and effective values then agree, Site Health keeps working, and the settings screen stops disagreeing with the database.

A slug list means a custom role carrying manage_options, promote_users, edit_users or edit_plugins passes straight through — and with the read-filter approach, Site Health now reports "good" for it too. Administrator clones from role-editor, membership and LMS plugins are exactly the population that ends up here.

A capability probe over wp_roles()->roles would produce the default set, still passed through default_role_excluded_roles so it stays adjustable. Worth checking wp_roles() availability at this point in the bootstrap first, since the filter is registered from default-filters.php.

Separately on the hook itself: it's currently removable, and the PR's own test_excluded_roles_can_be_removed uses __return_empty_array to restore administrator as the default role. If the intent is a floor rather than a suggestion, array_unique( array_merge( array( 'administrator', 'editor' ), (array) apply_filters( ... ) ) ) keeps it additive. If a genuine opt-out is wanted, that's fine — but the docblock should say that emptying the list re-enables self-registration into privileged roles.

Following on from @aaronjorbin's question about whether this guard is needed — whatever the answer, it currently fails open.

$filtering = false; at 9454 is only reached on the normal path. get_option( 'users_can_register' ) and the default_role_excluded_roles filter both run third-party callbacks in between, so if any of them throws and something upstream catches it, $filtering stays true for the rest of the request and every subsequent call returns the raw stored value — including administrator.

A try/finally around the body fixes it, and the re-entrant short circuit at 9433 returning 'subscriber' rather than $default_role would make that path fail closed too.

No test covers this. Nothing in the suite exercises a nested or throwing call, so a broken guard would surface in production rather than CI.

filter_default_role() is a new unprefixed global in wp-includes/functions.php. Core convention is wp_ or a leading underscore — _config_wp_home() and _mce_set_direction() nearby are the pattern.

This isn't only style. It's declared unconditionally and functions.php loads before plugins, so any plugin already defining a global filter_default_role() is a fatal "Cannot redeclare" on upgrade. That's the same shape as the wp_set_cookie() collision with WP Consent API on #12444, so a plugin-directory search on the final name seems worth doing before commit.

Also: @since 7.2.0 here versus 7.0.0 on the dropdown filter in options-general.php — worth a check that both are right for the release this actually lands in.